The present invention relates to techniques of mutually connecting networks conforming to the same protocol or networks conforming to different protocols.
For example, a method of using Twice NAT (Network Address Translation) (see http://www.ietf.org/rfc/rfc2663.txt, pp. 12–13) or a method of using a tunnel technique (see http://www.ietf.org/rfc/rfc2663.txt, p. 22) has been known as a technique of mutually connecting private networks through Internet to exhibit them as one VPN (Virtual Private Network). In any method, header information of an IP packet based on IPv4 and that of an IP packet also based on IPv4 are mutually translated in essentiality.
For example, in the basic NAT, translation between a private IPv4 address and a public IPv4 address is carried out. A router implementing a so-called Twice NAT technique in which two of NAT are connected in series is called a Twice NAT router. In the conventional basic NAT and bi-directional NAT, either one of source and destination addresses is rewritten, but in the Twice NAT technique, both the source address and destination address are rewritten at the time that a datagram passes through two domains connected by the Twice NAT router.
The Twice NAT is frequently used when an address space inside a private network collides with an address space of public space. In case a site is erroneously addressed by a public address of another site, even after a user given an address from a provider has transferred to another provider, the user continues to use the address assigned from the former provider for a while, and the latter provider assigns the same address to another user, resulting in generation of an address collision. To solve the address collision, the Twice NAT operates as follows. When a Host-A in the private domain starts communication with a Host-X in the public domain, the Host-A sends a DNS address query packet for the Host-X. A DNS-ALG (Domain Name Service-Application Level Gateway) captures this packet, translates the address for the Host-X to an address routable inside the private domain (Host-XPRIME), and returns it to the Host-A. When the DNS address resolution ends, the Host-A starts communication with the Host-XPRIME. At the time that this packet passes through the Twice NAT, the source address is rewritten to an address owned by the NAT, and the destination address is rewritten to the Host-X. A return packet from the Host-X is translated similarly to the above. Details of operation of the DNS-ALG are described in http://www.ietf.org/rfc/rfc2694.txt.
The method using the Twice NAT needs a translation table of large capacity when a great number of hosts communicate with each other through Internet. In case many applications use a specified IP address, there arises a problem that the dynamic address translation by the NAT using the DNS address query as a trigger, described as above, cannot fulfill itself. To solve this problem, apart from the NAT technique, there is available a method of mutually connecting two domains by using the tunnel technique. The method using the tunnel technique is restrained by such a condition that if terminals inside two networks being objects to be connected have the same address, communication cannot be permitted between the terminals having the same address, and two different domains to be connected must have the same subnet. However, there is no need of having the translation table of large capacity required during the use of the Twice NAT, and hence the tunnel technique is frequently used as a technique of mutually connecting private VLAN's (Virtual LAN's) sharing the same subnet space through Internet.
Each of the above-described examples is a technique used when a communication protocol of a network to which a terminal belongs is the same as that of a network to which a communication partner terminal belongs. When a communication protocol of a network to which a terminal belongs differs from that of a network to which a communication partner terminal belongs, NAT-PT (see http://www.ietf.org/rfc/rfc2766.txt, pp. 6–18, and http://www.ietf.org/rfc/rfc2765.txt, pp. 9–22) and SOCKS64 (see http://www.ietf.org/rfc3089.txt), for instance, have been known as a translation technique of connecting a network using, for example, IPv4 as protocol (hereinafter referred to as an “IPv4 network”) and a network using, for example, Internet Protocol version 6 as protocol (hereinafter referred to as an “IPv6 network”).
Essentially, in either method, the format of IP packet is mutually translated between IPv4 and IPv6. For example, a translation between IPv4 address and IPv6 address is carried out. A unit for performing this translation will hereinafter be called a “translator”. In the translator, for the sake of translation, correspondence relation between IPv4 address and IPv6 address must be prepared and held in advance of translation. When the correspondence relation is prepared dynamically each time that communication occurs, name resolution of DNS (Domain Name System) is used as a trigger for the preparation (see Internet RFC dictionary, published by ASCII, pp. 323–329).
The DNS is a system for translating a name (character string) comprehensible to human such as a URL of Web to an IP address. Operation to translate the name to the IP address will hereinafter be called “name resolution”. Today, almost all the applications on Internet acquire an IP address of a communication partner by utilizing this DNS.
The NAT and the translator take advantage of this fact, and constantly monitor messages of DNS interchanged upon commencement of communication to take a change of preparing translation information (such as the correspondence relation to IP address) of a request message for name resolution. Specifically, when an IPv6 terminal performs name resolution for a certain name and an IP address responsive thereto is based on IPv4, this IPv4 address is rewritten to an IPv6 address which in turn is returned to the IPv6 terminal. Then, the correspondence between the IPv4 address before rewriting and the rewritten IPv6 address is made. In other words, the DNS-ALG intercepts the response message for name resolution to rewrite it, and prepares translation information on the basis of information before rewriting and information after rewriting. The translation information dynamically prepared in this phase is temporary, and is discarded when the communication ends. The correspondence relation between IPv4 address and IPv4 address or the correspondence relation between IPv4 address and IPv6 address which is held by the DNS-ALG is discarded when the communication ends, and correspondence relation that differs communication by communication is used. Namely, the contents of rewrite of the response message for name resolution differ communication by communication. Accordingly, as viewed from the terminal making a request for name resolution, a different IP address is acquired for the same name.
As will be seen from the above, under conditions that almost all the applications on Internet dynamically acquire an IP address of a communication partner by utilizing the DNS, the cooperation of the DNS-ALG with the translator is a technique indispensable for connecting the IPv6 network and the IPv4 network. Further, the cooperation of the DNS-ALG with the Twice NAT is a technique for solving the IPv4 private address collision problem caused during transfer to the public address.
As described above, the mutual connection of VPN's based on the tunnel method faces a problem that it cannot deal with collision of IP addresses. The cooperation of the DNS-ALG with the Twice NAT is the technique for solving the IPv4 private address collision problem caused during transfer to the public address. In the cooperation of the DNS-ALG with the Twice NAT, however, there are problems that the address translation table is large, and that it is not scalable. Generally, the mutual connection between VPN's is often implemented by arranging the DNS-ALG and the Twice NAT in the edge of VPN. But, as the number of VPN's to be mutually connected increases, the address translation table becomes large. As a result, there is a problem that presentation of service is difficult to achieve.